@copilot Do you think we could change naga to do two additional passes import/export and link, and also provide a source mapping? How wild we go about it? Please explain

@copilot Do you think we could change naga to do two additional passes import/export and link, and also provide a source mapping? How wild we go about it? Please explain

Yes, adding import/export and linking to naga is technically feasible but would be a significant undertaking. Here's how it could be approached:

Architecture for Import/Export/Link

1. Import/Export Pass (Pre-parse or AST level)

Add new directive handling in naga/src/front/wgsl/parse/directive/:

export fn myFunction() { ... }
import "module_path" { myFunction, MyType }

This would:

• Extend the lexer/parser to recognize import/export keywords
• Track exported symbols in a new ExportTable structure
• Track import references as unresolved dependencies

2. Linking Pass (IR level)

Create a new naga/src/link/mod.rs module that:

• Takes multiple naga::Module instances
• Remaps all Handle<T> references when merging arenas (types, constants, functions, etc.)
• Resolves cross-module references using a symbol table
• Deduplicates equivalent types using UniqueArena
• Validates no circular dependencies exist

The trickiest part is handle remapping—naga's arena-based IR uses Handle<T> extensively, and merging modules requires translating all handles from source module arenas to the combined module.

3. Source Mapping

Naga already has Span infrastructure (naga/src/span.rs) that tracks byte offsets. To extend this:

• Add a SourceMap type mapping Span → (file_path, original_span)
• Modify parsing to accept file identifiers
• Preserve mappings through lowering and IR transformations
• Output source maps in a standard format (e.g., similar to JavaScript source maps)

Effort Estimate

• Import/Export syntax: ~2-3 weeks (parser changes, AST extensions)
• Linking pass: ~4-6 weeks (handle remapping, type deduplication, validation)
• Source mapping: ~2-3 weeks (span tracking through all passes)

Alternative: Expose Parser API

A lighter approach (as discussed in #6250) would be exposing naga's lexer/parser as a public API, letting tools like naga_oil handle composition at the source level before naga parsing. This is essentially what naga_oil does today but with regex-based preprocessing.